Methods and systems for clock synchronization in a network

ABSTRACT

Systems and methods for synchronizing clocks of a plurality of access points (APs) in a network are disclosed. In one implementation, a method includes receiving first information from at least one AP in the network. The first information may indicate whether each of the at least one AP is able to synchronize with a reference signal from a timing source. The method further includes obtaining network connectivity information of the plurality of APs, designating a first AP of the plurality of APs as a master node based on the first information and the network connectivity information, and assigning a second AP of the plurality of APs as a slave node to the master node based on the first information and the network connectivity information. The slave node may synchronize its clock to timing information provided by the master node.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of each of U.S. ProvisionalApplication Ser. No. 62/158,959, filed May 8, 2015, U.S. ProvisionalApplication Ser. No. 62/163,624, filed May 19, 2015, U.S. ProvisionalApplication Ser. No. 62/163,743, filed May 19, 2015, U.S. ProvisionalApplication Ser. No. 62/164,949, filed May 21, 2015, and U.S.Provisional Application Ser. No. 62/165,018, filed May 21, 2015, each ofwhich is hereby incorporated by reference in its entirety.

FIELD OF INVENTION

The present invention generally relates to clock synchronization and,more particularly, to a method and apparatus for synchronizing timeand/or frequency of clocks in a wireless access infrastructure.

BACKGROUND Conventional Wireless Access Infrastructure

A conventional wireless access infrastructure includes a radio accessnetwork and a core network typically owned, managed, and controlled by asingle wireless service provider, called the wireless carrier. The radioaccess network, such as the Evolved Universal Terrestrial Radio Access(E-UTRA) defined in 3GPP's Long Term Evolution (ITE) standard, containsthe network and equipment for connecting user equipment (UE), such asmobile devices and computers having wireless connectivity, to the corenetwork. The core network, such as the Evolved Packet Core (EPC) definedin the LTE standard, contains the network and equipment for providingmobile voice and data services within the carrier's service environmentand to external networks, such as the Internet, and other carriers'networks.

The LTE standard, for example, defines specific network nodes andcommunication interfaces for implementing the E-UTRA and EPC. Accordingto the standard, the E-UTRAN includes one or more eNodeB (base stations)configured to communicate with UEs and the EPC core network. The EPCincludes at least a Mobility Management Entity (MME), which managessession states, authentication, paging, and mobility and roamingfunctions; a packet-data gateway (PGW), which sends/receives datapackets to/from an external data network, such as the Internet; aServing Gateway (SG-W), which routes data packets between the PGW and aneNodeB; and a Policy and Charging Rules Function (PCRF), which managesusers, applications, and network resources based on carrier-configuredrules.

FIG. 1A is a schematic block diagram of an exemplary LTE wireless accessinfrastructure 1000 including an E-UTRAN 1100 and an EPC 1200. TheE-UTRAN 1100 includes at least one eNodeB 1102 configured to communicatewith UEs 1002A and 1002B over wireless links. The EPC 1200 containsnetwork nodes including a MME 1202, SG-W 1204, PGW 1206, and PCRF 1208.While the exemplary infrastructure 1000 is depicted with only one PGW1206 connected to an external packet-data network, such as the Internet,the EPC 1200 alternatively may contain multiple PGWs, each connectingthe EPC 1200 to a different packet data network. The MME 1202, SG-W1204, POW 1206, and PCRF 1208 are implemented in software on dedicatedhardware (computers) 1302, 1304, 1306, and 1308. The dedicated hardwaremay be a single server or a cluster of servers. The LTE network nodes1202, 1204, 1206, and 1208 are typically implemented as monolithicsoftware modules that execute on their respective dedicated hardware1302, 1304, 1306, and 1308.

The LTE standard not only defines functionalities in each of the MME1202, SG-W 1204, PGW 1206, and PCRF 1208, but also defines thecommunication interfaces between them. The LTE standard defines severalinterfaces including, for example, an “S1-MME” interface between theeNodeB 1102 and the MME 1202, an “S1-U” interface between the eNodeB1102 and the SG-W 1204, an “S11” interface between the MME 1202 and theSG-W 1204, an “S5” interface between the SG-W 1204 and the PGW 1206, anda “Gx” interface between the PCRF 1208 and the POW 1206. The exemplaryinfrastructure 1100 illustrates these standardized interfaces.

Because the communication interfaces and network nodes in the LTEwireless access infrastructure 1000 are standardized, they ensurecompatibility between the MME 1202, SG-W 1204, PGW 1206, and PCRF 1208,even when those nodes are programmed and/or developed by differentmanufacturers. Such standardization also ensures backward compatibilitywith legacy versions of any nodes that may have been previously deployedin the infrastructure 1000.

The need for multiple, dedicated network nodes makes deployment of anLTE wireless access infrastructure, such as the exemplary infrastructure1000, costly and complex. Further, the standardization of functionsperformed by nodes in the radio access and core networks, and thestandardized communication interfaces between nodes in those networks,makes integration of these types of networks with solutions outside thestandard, such as enterprise solutions (e.g., deployed within aproprietary enterprise network), challenging. The standardized nodes andinterfaces in conventional wireless access infrastructures also makescaling the infrastructure challenging. For example, it may be difficultto deploy only a subset of the functions and/or communication interfacesdefined by the standard. Furthermore, conventional wireless accessinfrastructures may not utilize resources efficiently within theinfrastructure. In some conventional wireless access solutions, forexample, a UE may be denied voice and/or data services because one ofthe network nodes is unable to handle an additional user even thoughother nodes are not being fully utilized. In other words, the capacityof the conventional infrastructure may be limited by the capacity ofeach node.

Synchronizing Clocks of Nodes in a Wireless Access Infrastructure

In many wireless access infrastructures, it is desirable to synchronizetime (phase) and/or frequency of clocks used by the various networknodes. Such synchronization may enable more efficient and robustoperation in the wireless infrastructure, which in turn can reduce theprobability of interference between calls, dropped calls, and packetloss/collisions, among other things. In the LTE wireless accessinfrastructure 1000, for example, it may be desirable to synchronize thefrequencies of clocks in the UEs 1002A-B and eNodeB 1102 to an accuracyof 50 parts-per-billion (ppb) or less, and synchronize the clocks innodes within the EPC 1200 to an accuracy of 16 ppb or less. For atime-division duplex (TDD) LTE wireless access infrastructure, the phaseof different clocks in the infrastructure may be synchronized, forexample, to an accuracy of 1.5 microseconds or less.

One technique for synchronizing time or frequency of clocks in networknodes uses an atomic-clock signal transmitted from the Global NavigationSatellite System (GNSS). FIG. 1B illustrates an exemplary wirelessaccess infrastructure 1000 using this technique. In FIG. 1B, everyeNodeB in the network (including 1202) may include, or is otherwiseconnected to, a GNSS receiver. In this example, each GNSS receiverreceives the same atomic-clock signal from GNSS satellites 1400, and theatomic-clock signal may be used to synchronize local clocks running ineach network node. This solution, however, may be impractical insituations where some of the nodes are in a location that cannot receivethe GNSS signals, such as inside buildings without windows.Additionally, equipping every node with a GNSS receiver may beprohibitively costly for many applications.

Another technique for synchronizing time or frequency of clocks uses oneor more dedicated “master” nodes that distribute a reference clocksignal to other “slave” nodes, which may be the nodes in the EPC 1200and E-UTRAN 1100, for example. In FIG. 1C, for example, every node inthe exemplary wireless access infrastructure 1000 synchronizes the timeand/or frequency of a local clock to a reference clock signal receivedfrom a master node 1500. In this example, the nodes 1102, 1202, 1204,1206, and 1208 are slave nodes relative to the master node 1500. In someimplementations, the master node 1500 may be configured as a PrecisionTiming Protocol (PTP) server, as defined in the IEEE 1588 standard, thatsends and receives a series of time-stamped messages to/from the slavenodes 1102, 1202, 1204, 1206, and 1208. The slave nodes may use thetime-stamped messages to account for phase and/or frequency offsets withtheir local running clock, thereby allowing them to synchronize time orfrequency of their local clocks with the master node 1500. The masternode 1500 may include a GNSS receiver 1502 and may synchronize its timeand/or frequency with a reference timing source, such as received fromGNSS satellites 1400, or from another timing source, such as a“grandmaster” node 1600.

TERMINOLOGY

“Frequency synchronization” broadly refers to adjusting the operatingfrequency of one or more clock signals to synchronize their frequencyusing a reference clock signal.

“Phase synchronization” broadly refers to adjusting the phase of one ormore clock signals to synchronize their relative phases using areference clock signal. Frequency synchronization is a prerequisite forphase synchronization.

“Time synchronization” broadly refers to adjusting one or more clocksignals so they are synchronized to the same absolute time value. Bothfrequency and phase synchronization are prerequisites for timesynchronization.

“Clock synchronization” may refer to frequency synchronization, phasesynchronization, or time synchronization. As used herein, clocksynchronization may be referred to as synchronizing in time and/orfrequency with one or more clock signals.

A “timing source” broadly refers to any software or hardware that may beused to provide one or more reference signals used for clocksynchronization. The timing source may be implemented at a singlelocation, such as in a network node, or may be distributed acrossmultiple locations, such as GNSS satellites. The reference signals mayreflect an absolute time signal, indicative of a current time, or arelative time signal, indicative of a time measured from a predeterminedstarting point.

SUMMARY

The invention provides a novel system and method for clocksynchronization in cloud-based wireless access infrastructures.

The disclosed embodiments of the invention include a novel set offunctions that dynamically designates access points (APs) as a masternode or a slave node based on information received from the APs as wellas information related to the network connectivity of the APs. Theinformation received from the APs include, for example, whether an APhas the necessary hardware and/or software to synchronize its localclock with GNSS satellites. The information related to the networkconnectivity of the APs may include, for example, a network map.

An AP may be used to provide wireless network access to one or more UEsin accordance with the disclosed embodiments. The AP may provide one ormore radio-network functions and one or more core-network functions foreach UE in communication with the AP. In some embodiments, radio-networkfunctions in the AP may be configured to receive information from the UEand pass that information to core-network functions allocated for theUE. The AP also may include a distributed portion of a serviceconfigured to receive the information from the core-network functionsand communicate the information to a corresponding cloud portion of theservice running on a cloud platform. The cloud portion of the service onthe cloud platform may process the information and return a response toits corresponding distributed portion on the AP.

The disclosed embodiments of the invention may include one or more APsthat are configured to receive a reference clock signal from a timingsource, such as GNSS satellites, and further configured to synchronizetime and/or frequency of one or more clock signals with the referenceclock signal. The APs may communicate with a location managementfunction (LMF). For example, an AP having configured to receive GNSSsignals (e.g., using a GNSS receiver) may notify the LMF whether the APis able to obtain a lock on the GNSS signals.

Further to the disclosed embodiments, a timing management function (TMF)may designate each AP as a master node or a slave node. The TMF mayassign one or more slave nodes to a master node. In some embodiments,the TMF may assign a slave node to a plurality of master nodes. In theseembodiments, the slave node may be configured to synchronize with afirst master node of the plurality of the master nodes and switch overto a second master node when the first master node become unavailable(e.g., when the first master node loses a lock to a GNSS signal) or whenthe number of slave nodes assigned to the first master node exceeds apredetermined number. In some embodiments, the TMF may determine whichAPs to designate as master or slave nodes based on whether an AP isconfigured to receive signals from a timing source (e.g., whether an APhas a lock on a GNSS signal). For example, the TMF may assign an AP as amaster node, when the AP has a lock to a GNSS signal. The APs may sendinformation to the LMF, and the TMF may obtain the information from theLMF.

Additionally, the TMF may rely on connectivity information to determinewhich APs to designate as master or slave nodes and to determine whichmaster node to assign slave nodes. The connectivity information mayinclude, for example, a network map including performance and/or costassociated with each interconnection between nodes in the network. Insome embodiments, the TMF may obtain the connectivity information from aconnectivity management function (CMF) on the AP. The TMF maycommunicate with the LMF to obtain information relating to an AP'sability to receive signals from a timing source and synchronizefrequency and/or time of clocks with the timing-source signal.

According to the disclosed embodiments, the TMF may dynamically changewhether an AP is designated as a slave or master node, and which slavenodes are assigned to a master node. In some embodiments, the TMF maychange the master/slave designation or assignment of an AP in responseto information obtained from at least one of the CMF and LMF. Theinformation obtained from the CMF and/or LMF may include a list ofadditional APs that are now able to synchronize with the timing source,a list of current “master” APs that are now unable to synchronize withthe timing source, updated network connectivity information (e.g.,identification of new switches or routers in the network, upgradednetwork nodes, etc.), to provide some examples. The AP may receive othertypes of information from the CMF and/or LMF in addition to, or insteadof, any of the exemplary types of information noted above.

According to the disclosed embodiments, the TMF may designate one AP asa master node when none of the APs successfully synchronizes with thetiming source. In some embodiments, the TMF may designate as a masternode an AP that successfully synchronizes one or more clock signals witha non-absolute timing-source signal (i.e., a reference clock signal nottied to a specific time). For example, the TMF may designate an AP thatsupports the network timing protocol (NTP), which is a standardprotocol, as a master node. In some embodiments, the TMF may designatean AP as a slave node when the AP has the necessary hardware and/orsoftware and is able to synchronize with the timing source. In someembodiments, the TMF may designate an AP as a master node, but notassign any slave nodes to the AP.

According to the disclosed embodiments, one or more of the TMF, CMF, andLMF may be executed in a cloud platform, in a server of an enterprisenetwork, or within one or more APs. In some embodiments, one or more ofthe TMF, CMF, and LMF may be combined at the software level and/orexecuted on the same hardware platform. In accordance with the disclosedembodiments, one or more of the TMF, CMF, and LMF may be provided as oneor more services having a cloud portion and a distributed portion in acloud platform.

According to the disclosed embodiments, a method for synchronizingclocks of a plurality of access points (APs) in a network includesreceiving first information from at least one AP in the network. Thefirst information may indicate whether each of the at least one AP isable to synchronize with a reference signal from a timing source. Themethod further includes obtaining network connectivity information ofthe plurality of APs, designating a first AP of the plurality of APs asa master node based on the first information and the networkconnectivity information, and assigning a second AP of the plurality ofAPs as a slave node to the master node based on the first informationand the network connectivity information. The slave node may synchronizeits clock to timing information provided by the master node.

According to the disclosed embodiments, a system for synchronizingclocks of a plurality of access points (APs) in a network includes alocation management function (LMF) configured to receive firstinformation from at least one AP of the plurality of APs. The firstinformation may indicate whether each of the at least one AP is able tosynchronize with a reference signal from a timing source. The systemfurther includes a connectivity management function (CMF) configured toobtain network connectivity information of the plurality of APs and atiming management function (TMF). The TMF may be configured to designatea first AP of the plurality of APs as a master node based on the firstinformation and the network connectivity information, and assign asecond AP of the plurality of APs as a slave node to the master nodebased on the first information and the network connectivity information.The slave node may synchronize its clock to timing information providedby the master node.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this disclosure, illustrate various disclosed embodiments. Inthe drawings:

FIGS. 1A-C are schematic block diagrams of an exemplary wireless accessinfrastructures.

FIG. 2 illustrates a schematic block diagram of an exemplary cloud-basedwireless access infrastructure in accordance with the disclosedembodiments.

FIG. 3 illustrates another illustrative block diagram of the exemplarycloud-based wireless access infrastructure of FIG. 2 in accordance withthe disclosed embodiments.

FIG. 4 illustrates another illustrative block diagram of the exemplarycloud-based wireless access infrastructure of FIGS. 2 and 3 inaccordance with the disclosed embodiments.

FIG. 5 illustrates a process performed by a set of functions including aCMF, LMF, and TMF in accordance with the disclosed embodiments.

DETAILED DESCRIPTION OF DISCLOSED EMBODIMENTS

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar parts.While several illustrative embodiments are described herein,modifications, adaptations and other implementations are possible. Forexample, substitutions, additions, or modifications may be made to thenodes and steps illustrated in the drawings, and the illustrativemethods described herein may be modified by substituting, reordering,removing, or adding steps to the disclosed methods. Accordingly, thefollowing detailed description is not limited to the disclosedembodiments and examples. Instead, the proper scope of the invention isdefined by the appended claims.

Cloud-Based Wireless Access Infrastructure

FIG. 2 illustrates a block diagram of an exemplary cloud-based wirelessaccess infrastructure 2000 in accordance with the disclosed embodimentsof the invention. The exemplary cloud-based wireless accessinfrastructure 2000 may provide one or more access points (APs) 2110through which users may communicate to access standardized wirelessvoice and/or data services, such as defined in the LTE standard, as wellas enterprise-level applications and services that would be available tothe user in an enterprise network of a corporate, governmental,academic, non-profit, or other organization or entity. For example, inaccordance with the disclosed embodiments, an organization may deploythe APs 2110 in a building to provide its employees in that buildingwith wireless access to both LTE and enterprise-level services.

The exemplary cloud-based wireless access infrastructure 2000 includesat least first and second UEs 2120A-B, one or more antennas 2130, theAPs 2110, one or more network devices 2150, a network controller 2500, acloud platform 2200, an enterprise network 2300, and an internetprotocol exchange (IPX) 2400.

As shown in FIG. 2, each of the UEs 2120A-B may communicate with the APs2110 through the antenna 2130 electrically coupled to the APs 2110.While a single antenna is shown in FIG. 2, the cloud-based wirelessaccess infrastructure 2000 may alternatively employ multiple antennas,each electrically coupled to the APs 2110. In some embodiments, one ormore antennas 2130 may connect to the one or more APs in the APs 2110and other antennas may connect to different APs in the APs 2110. Each APin the APs 2110 may be implemented on one or more computer systems. AnAP, for example, may execute one or more software programs on a singlecomputer or on a cluster of computers. Alternatively, an AP may beimplemented as one or more software programs executing on one or morevirtual computers.

In the disclosed embodiments, the APs 2110 may be connected to one ormore network devices 2150, which may be configured to forward databetween the UEs 2120A-B (via the APs 2110) and external data networks,such as the Internet 2600 and/or the cloud platform 2200. The networkdevices 2150 may include, for example, a hub, switch, router, virtualswitches/router, distributed virtual switch (vSwitch), DHCP server,and/or any combination thereof.

In some embodiments, at least a subset of the network devices 2150 maybe dynamically configured by a software-defined networking (SDN)controller. For example, as shown in FIG. 2, a SDN controller 2500 mayconfigure one or more layer-two devices (e.g., switches) or layer-threedevices (e.g., routers) in the set of network devices 2150, such thatdata packets or frames may be routed, processed, and/or blocked at thenetwork devices based on various parameters, such as, but not limitedto, the origin or destination of the data, type of data, and/or carrieror enterprise policies. Additionally, or alternatively, the SDNcontroller 2500 may configure at least a subset of the network devices2150 to provide different qualities of service (QoS) to different UEsbased on one or more policies associated with each UE. For example, theSDN controller 2500 may configure the one or more network devices 2150to ensure that the UE 2120A, which may be associated with a businesscustomer, receives a higher QoS compared with the UE 2120B, which may beassociated with a non-business customer.

In some embodiments, the SDN controller 2500 may configure one or moreof the network devices 2150 based on data (including, for example,messages, notifications, instructions, measurements, authorizations,approvals, or other information) received from one or more servicesrunning in the cloud-based wireless access infrastructure 2000. Forexample, the SDN controller 2500 may receive instructions on how andwhich of the network devices 2150 to configure from a service on thecloud platform 2200.

In accordance with the disclosed embodiments, the cloud platform 2200may communicate with the enterprise network 2300 and/or the IPX 2400. Insome embodiments, the cloud platform 2200 may include direct connectionsto the enterprise network 2300 or may employ indirect connections, suchas using the Internet 2600 (via the network device 2150), to communicatewith the enterprise network 2300. For example, the cloud platform 2200may communicate with the enterprise network 2300 through the Internet2600 using a tunneling protocol or technology, such as the IPSecprotocol, or may communicate with an LTE EPC 1200 node of anothercarrier via the IPX 2400 using one or more standardized interfaces, suchas the Gy, Gz, Gx, and S6a interfaces as defined in the LTE standard. InFIG. 2, the enterprise network 2300 is shown to be separate, butelectrically coupled, with the cloud platform 2200. In other embodiments(not shown), however, the enterprise network 2300 may be implemented onthe cloud platform 2200.

Services of Cloud-Based Wireless Access Infrastructure

FIG. 3 illustrates another illustrative block diagram of the exemplarycloud-based wireless access infrastructure 2000 of FIG. 2 in accordancewith the disclosed embodiments. FIG. 3 illustrates additionalimplementation details of the APs 2110, cloud platform 2200, andenterprise network 2300 that may be used in the exemplary cloud-basedwireless access infrastructure 2000.

As shown in FIG. 3, at least one AP in the APs 2110 may be configured toexecute one or more instances of a software program configured toimplement functions of a base station and one or more instances of asoftware program configured to implement functions of a core network.For example, in FIG. 3, eNodeB Functions 2112A-B represent at least twoinstances of a software program configured to provide at least a subsetof functions of an LTE base station, such as the eNodeB 1102. Similarly,EPC Functions 2114A-B represent at least two instances of a softwareprogram configured to provide at least a subset of functions of an LTEcore network, such as the EPC 1200. In some embodiments, the AP may beconfigured to execute one or more instances of a single software programconfigured to implement both the eNodeB Functions and EPC Functions.

In some embodiments, a fixed number of instances of eNodeB Function2112A-B and a fixed number of instances of EPC Function 2114A-B may beinstantiated and maintained in an AP. The number of instances of theeNodeB Functions 2112A-B and the number of instances of the EPCFunctions 2114A-B may be the same or different. In some embodiments,when a UE 2120A wirelessly connects to the AP, an existing instance ofeNodeB Function 2112A and an existing instance of EPC Function 2114A maybe assigned to handle communications with the UE 2120A. In otherembodiments (e.g., when existing instances of eNodeB Function 2112A andEPC Function 2114A are unavailable to assign to the UE 2120A), the APmay instantiate a new instance of an eNodeB Function and a new instanceof an EPC Function for the UE 2120A. In alternative embodiments, the APmay dynamically instantiate and assign a new instance of eNodeBFunctions and a new instance of EPC Functions for each UE.

According to the disclosed embodiments, an instance of the eNodeBFunctions 2112A may be configured to provide all radio-related functionsneeded to send/receive data to/from a UE 2120A. For example, an instanceof eNodeB Function 2112A may perform at least a subset of functions ofan eNodeB as defined in the LTE standard including, but not limited to,functions of a physical (PHY) layer, media access control (MAC) layer,radio resource management (RRM), and/or self-organizing network (SON).Functions of a PHY layer (as defined in the LTE standard) may include,for example, channel coding, rate matching, scrambling, modulationmapping, layer mapping, pre-coding, resource mapping, orthogonalfrequency-division multiplexing (ODFM), and/or cyclic redundancychecking (CRC). Functions of MAC layer (as defined in the LTE standard)may include, for example, scheduling, multiplexing, and/or hybridautomatic repeat request (HARQ) operations. Functions of RRM (as definedin the LTE standard) may include, for example, allocating, modifying,and releasing resources for transmission over the radio interfacebetween a UE 2120A and the AP. Functions of a SON (as defined in the LTEstandard) may include, for example, functions to self-configure,self-optimize, and self-heal the network devices 2150. Alternatively, oradditionally, an instance of eNodeB Function 2112A may perform at leasta subset of functions of an element equivalent to an eNodeB in otherwireless standards, such as, but not limited to, functions of a basetransceiver station (BTS) as defined in the GSM/EDGE standard or a NodeBas defined in the UMTS/HSPA standard. In some embodiments, a UE 2120Amay wirelessly connect to the AP in the 3.5 GHz shared band.

According to the disclosed embodiments, an instance of eNodeB Function2112A may be further configured to send/receive data to/from acorresponding instance of EPC Function 2114A. However, in contrast withthe conventional wireless access infrastructure 1000 of FIG. 1A thatonly uses standardized communication interfaces, an instance of theeNodeB Function 2112A in the AP may communicate with an instance of theEPC Function 2114A also executing in the AP using any interface orprotocol. Because the eNodeB and EPC Functions execute on the same AP,they do not need to be constrained to standardized communicationinterfaces. Instances of eNodeB Functions 2112A and EPC Functions 2114Amay communicate with one another using, among other things,language-level method or procedure calls, remote-procedure call (RPC),Simple Object Access Protocol (SOAP), or Representational State Transfer(REST).

In accordance with the disclosed embodiments, an instance of the EPCFunctions 2114A may be configured to provide at least some functions ofa core network. For example, the exemplary instance of EPC Function2114A may include functions such as, but not limited to, at least asubset of functions of the MME 1202, PGW 1206, SG-W 1204, and/or PCRF1208 of EPC 1200 as defined in the LTE standard. An instance of the EPCFunction 2114A, for example, may include a Mobility Management Function(MMF) which may perform at least a subset of functions of the MME 1202(e.g., authentication functions) and the Optimized Packet Function (OPF)which may perform at least a subset of functions of the SG-W 1204 and/orthe PGW 1206 node (e.g., forwarding packets between the UE 2120A and oneor more external data networks, such as the Internet 2600 and IPX 2400).

In contrast with the MME 1202 node defined in the LTE standard, the MMFexecuting in the AP may communicate with the OPF using any protocolbecause both functions are implemented in the same EPC Function 2114A.On the other hand, in the EPC 1200, the MME 1202 node is connected tothe SG-W 1204 using the standardized interface S 11 and the SG-W 1204 isconnected to the POW node using the standardized interfaces S5/S8. Inthe disclosed embodiments, for example, the MME 1202 and the OPF nodemay communicate with one another using language-level methods orprocedure calls, RPC, SOAP, or HTTP/REST.

Advantageously, an instance of eNodeB Function 2112A and/or EPC Function2114A may implement the functions (or a subset of functions) of theeNodeB 1102 and/or the EPC; 1200 using one or more services inaccordance with the disclosed embodiments. For example, a service 2210Amay include a distributed portion 2212A and a cloud portion 2214A. Thedistributed portion 2212A may be implemented within the AP and mayprovide application programming interfaces (APIs) that may be accessibleby instances of eNodeB Functions 2112A-B and/or EPC Functions 2114A-B.The cloud portion 2214A of the service 2210A may be utilized byinstances of the eNodeB Functions 2112A-B and/or EPC Functions 2114A-Bthrough the associated distributed portion 2212A running on the AP.

Unlike the conventional wireless access infrastructure 1000 of FIG. 1,the exemplary cloud-based wireless access infrastructure 2000 mayutilize available resources more efficiently, in part, because theservices (e.g., 2110A-B) share the same pool of cloud-platformresources, and further, the cloud platform 2200 may dynamicallyreallocate resources to and from each service based on the service'sresource needs. For example, in the cloud-based wireless accessinfrastructure 2000, the cloud platform 2200 may dynamically allocatecomputing resources, such as memory and CPU time, to various servicesbased on each service's real-time demand for such resources. Incontrast, a predetermined amount of resources would be dedicated to eachnode in the conventional wireless access infrastructure 1000, and theseresources cannot be distributed among the other nodes dynamically.Therefore, situations may exist in the conventional wireless accessinfrastructure 1000 where the UE 1002A is denied service because one ofthe nodes (e.g., the MME 1202 of the EPC 1200) does not have sufficientamount of resources available for the UE 1002A, even when resources ofother nodes have not been fully utilized.

Moreover, the capacity of the exemplary cloud-based wireless accessinfrastructure 2000 may be simpler and easier to scale up or downcompared with the capacity of the conventional wireless accessinfrastructure 1000. For example, the capacity of the cloud-basedwireless access infrastructure 2000 may be increased by adding moreresources available to the cloud platform 2200 and/or to the APs 2110.In contrast, capacities of multiple EPC 1200 nodes may need to beincreased to increase the capacity of the conventional wireless accessinfrastructure 1000.

According to the disclosed embodiments, the cloud portion 2214A of theservice 2210A may be implemented on the cloud platform 2200. Examples ofcloud platforms include, Eucalyptus (an open-source cloud platform),Open Stack (an open-source cloud platform), and Amazon Web Service(AWS). In some embodiments, the cloud portion 2214A of the service 2210Amay be stateless and communicate with the distributed portion 2212A ofthe service 2210A using a protocol supported by the cloud platform 2200(e.g., HTTP/REST and SOAP are supported by AWS). In some disclosedembodiments, the cloud portion 2214A of the service 2210A may utilize acloud portion 2214B of another service 2210B. In other disclosedembodiments, a cloud portion 2214C of a service 2210C may communicatewith a conventional core network node in IPX 2400 by a standardizedinterface. In some embodiments, the cloud portion 2214C of the service2210C may communicate with a server/application (e.g., EnterpriseIdentity and Authentication Application (EIAA) 2310) of the enterprisenetwork 2300. And in some embodiments, the cloud portion 2214C of theservice 2210C may communicate with the SDN controller 2500 to provideinstructions on how and which network devices of the network devices2150 to configure/reconfigure. In some embodiments, a service may have acloud portion only (i.e., without corresponding distributed portions),such as the cloud portion 21143 of the service 22101B.

In some embodiments of the invention, the distributed portion 2212A ofthe service 2210A, in addition to exposing APIs to instances of eNodeBFunctions 2112A-B and/or EPC Functions 2114A-B, may provide additionalfunctions, such as caching. For example, when an API of the distributeportion 2212A of the service 2210A is being utilized to request data,the distributed portion 2212A, prior to communicating with itsassociated cloud portion 2214A to obtain the requested data, maydetermine whether the data is cached and/or whether the cached data isstill valid.

Time/Frequency Synchronization of APs

FIG. 4 illustrates another illustrative block diagram of the exemplarycloud-based wireless access infrastructure 2000 of FIGS. 2 and 3 inaccordance with the disclosed embodiments. FIG. 4 illustrates additionalimplementation details of the APs 2110 and the cloud platform 2200,including components for synchronizing time and/or frequency among theAPs 2110.

FIG. 4 shows the APs 2110 including a first AP 2110A, a second AP 2110B,and a third AP 2110C. The first AP 2110A and the second AP 2110B eachincludes a GNSS receiver 2116A-B configured to synchronize time and/orfrequency with GNSS satellites 1400. In the exemplary infrastructure ofFIG. 4, the first AP 2110A may successfully synchronize time and/orfrequency with the GNSS satellites 4010, but the second AP 2110B may beprevented from synchronizing time and/or frequency with the GNSSsatellites because of adverse weather, for example. In other words,while both the first AP 2110A and the second AP 2110B are considered tohave the necessary hardware and/or software to synchronize in timeand/or frequency with the GNSS satellites, only the first AP 2110A ofthe two APs is considered to be in a situation where it is able tosynchronize time and/or frequency with the satellite's signal. The thirdAP 2110C does may not synchronize time nor frequency with the GNSSsatellites because the third AP 2110C does not have a GNSS receiver.That is, the third AP 2110C is not considered to have the necessaryhardware/software to synchronize in time and/or frequency.

FIG. 4 further shows a connectivity management function (CMF) service,timing management function (TMF) service, and location managementfunction (LMF) service. A “function” broadly refers to a software orhardware configured to perform one or more predetermined operations. Afunction may be implemented as a software executing on a hardware;alternatively, the function may be implemented as a dedicated hardware.A function may also be implemented as a service on a cloud platform.

A service (e.g., CMF, LMF, or TMF service) may include a distributedportion (e.g., 4020A, 4030A, or 4040A) executing in each AP 2110A-C anda corresponding cloud portion (e.g., 4020B, 4030B, or 4040B) executingon the cloud platform 2200. As noted above, a distributed portion of aservice in an AP may communicate with the corresponding cloud portion ofthe service via the network devices 2150. The APs 2110A-C may alsocommunicate among each other via the network devices 2150. The cloudportions of services may communicate among each other within the cloudplatform 2200 using an internal network infrastructure of the cloudplatform 2200, or alternatively may communicate with other service cloudportions via the network devices 2150.

In some embodiments, APs that have the necessary hardware and/orsoftware and are in situations to be able to synchronize time and/orfrequency with the timing source, such as the GNSS satellites 1400, maycommunicate with the LMF service. In the exemplary infrastructure ofFIG. 4, for example, the first AP 2110A may notify the cloud portion ofthe LMF service (“C-LMF”) 40601, using the distributed portion of theLMF service (“D-LMF”) 4060A executing in the first AP 2110A, that thefirst AP 2110A includes, or has access to, a GNSS receiver and that theGNSS receiver has a lock on a GNSS signal. Further, the second AP 2110Bmay notify the C-LMF 40601, using the D-LMF 4060A in the second AP 2110Bincludes, or has access to, a GNSS receiver but that the GNSS receiverdoes not have a lock on a GNSS signal. Additionally, the third AP 2110Cmay notify the C-LMF 4060B, using the D-LMF 4060A in the third AP, thatthe third AP 2110C does not include, or have access to, a GNSS receiver.Alternatively, the third AP 2110 (or any other AP that does not have aGNSS receiver) may not communicate with the C-LMF, and the C-LMF mayassume that an AP does not have the hardware/software necessary tosynchronize with the GNSS satellites, unless the AP communicatesotherwise. In some embodiments, C-LMF may have a prior information as towhich AP has the necessary hardware/software to synchronize time and/orfrequency with the timing source.

According to the disclosed embodiments, the TMF service may designate anAP as a master node or a slave node. In the exemplary infrastructure ofFIG. 4, for example, a cloud portion of the TMF service (“C-TMF”) 4020Bmay designate an AP as a master node or a slave node and assign one ormore slave nodes to a designated master node. In some embodiments, theC-TMF 4020B may designate an AP as a master or slave node based onwhether the AP has the necessary hardware and/or software to synchronizein time and/or frequency with a signal from a timing source (e.g., byhaving a GNSS receiver), and/or whether the AP is in a position where itis able to synchronize in time and/or frequency with the timing source(e.g., by having a lock on a GNSS signal). In the exemplaryinfrastructure 2000 of FIG. 4, for example, the C-TMF 4020B maycommunicate with the D-TMF 4020A of the first AP 2110A to designate thefirst AP 2110A as a master node since the first AP 2110A has a GNSSreceiver 2116A and the GNSS receiver 2116A has a lock on a GNSS signal.The C-TMF 4020B may further communicate with the D-TMF 4020A of thesecond AP 2110B to designate the second AP 2110B as a slave node sincethe second AP 2110B has a GNSS receiver 2116B, but the GNSS receiver2116B is unable to lock on a GNSS signal because of, for example,inclement weather or any other reason resulting in low signal-to-noise.The C-TMF 4020B may also communicate with the D-TMF 4020A of the secondAP 2110B to assign the second AP 2110B as a slave node to the first AP2110A designated as a master node. Additionally, the C-TMF 4020B maycommunicate with the D-TMF 4020A of the third AP 2110C to assign thethird AP 2110C as a slave node to the first AP 2110A.

According to the disclosed embodiments, the TMF service may rely onconnectivity information to determine which APs to designate as masteror slave nodes and to determine which master nodes should be assignedslave nodes. In the exemplary infrastructure of FIG. 4, for example, theC-TMF 4020B may rely on network connectivity information to determinewhich APs to designate as master or slave nodes and determine whichmaster node to assign slave nodes. The connectivity information mayinclude, for example, a network map including performance and/or costassociated with each interconnection between the nodes in the network.

Alternatively, the C-TMF 4020B may assign the second and/or third APs2110B-C as slave nodes to another AP designated as a master node. Forexample, where the second and third APs 21100B-C are able to communicatewith another AP that has been designated as a master node using lesshops, delay, or cost as compared to the first AP 2110A, which is also amaster node, the C-TMF 4020B may assign the second and third APs 2110B-Cto be slave nodes to the new AP master node instead of using the firstAP 2110A as their master node. In some embodiments, the C-TMF 4020B maycommunicate with the C-LMF 4060B to obtain information on whether an APhas the necessary hardware and/or software for clock synchronization,and whether the AP is able to synchronize in time and/or frequency witha reference signal from a timing source. In some embodiments, the C-TMF4020B may obtain the network connectivity information from the C-CMF4040B. In some embodiments, C-CMF 4040B may obtain the networkconnectivity information from a network administrator.

In embodiments where a slave node can be assigned to a plurality ofmaster nodes, the C-TMF 4020B may assign the slave node to master nodesthat uses different network technologies and/or are located in differentgeographical locations. In these embodiments, the probability of allmaster nodes (assigned to the slave node) failing at the same time maybe reduced.

According to the disclosed embodiments, the C-TMF 4040B may dynamicallyre-designate an AP as a slave or master node. In some embodiments, theC-TMF 4020B may change the designation of an AP in response toinformation obtained from the C-CMF 4040B and/or C-LMF 4060B. Theinformation obtained from the C-CMF 4040B and/or C-LMF 4060B may includea list of master APs that are now able or unable to synchronize with thetiming source, an updated network connectivity information (e.g., newrouter, upgraded networked connection, etc.), to provide some examples.

According to the disclosed embodiments, the C-TMF 4040B may dynamicallychange which master node a slave node is assigned to. In someembodiments, the C-TMF 4020 may change the assignment of an AP inresponse to information obtained from the C-CMF 4040B and/or C-LMF4060B. The information obtained from the C-CMF 4040B and/or C-LMF 4060Bmay include a list of master APs that are now unable to synchronize withthe timing source or an updated set of network connectivity information(e.g., identifying new routers in the network, upgraded networkedconnections, etc.), to provide some examples.

Further to the disclosed embodiments, the C-TMF 4020B may designate anAP as a master node, when none of the APs successfully synchronizes withthe timing source. In the exemplary infrastructure 2000 of FIG. 4, forexample, when the master-node AP 2110A loses its lock on the GNSS signaland no other APs are able to synchronize time and/or frequency with asignal from the GNSS satellite, the C-TMF 4020B may arbitrarilydesignate the AP 2110B as a master node and assign all other APs to beslave nodes to the AP 2110B. Alternatively, the C-TMF 4020B maydesignate an AP that successfully synchronizes with a non-absolutetiming source as a master node. For example, in the exemplaryinfrastructure 2000 of FIG. 4, when the AP 2110C supports the networktiming protocol (NTP), a standard protocol, the C-TMF 4020 may designatethe AP 2110C as a master node even though the AP 2110C is not able tosynchronize time nor frequency with the GNSS satellites.

In some embodiments, the C-TMF 4020B may designate an AP as a masternode, but not assign any slave nodes to the AP.

FIG. 5 illustrates a process 5000 performed by a set of functionsincluding a CMF, LMF, and TMF in accordance with the disclosedembodiments. The process may synchronize clocks of a plurality of accesspoints (APs).

At step 5010, an LMF may receive first information from at least one APof the plurality of APs, the first information including informationindicating whether each of the at least one AP is able to synchronizewith a signal from a timing source, such as a reference clock signalfrom the timing source. In some embodiments, the LMF, CMF, and TMF maybe separate services executing on at least one cloud platform. In someembodiments, the LMF may receive the first information through adistributed portion for the LMF. The distributed portion for the LMF mayexecute on the at least one AP. In some embodiments, the firstinformation may further include whether each of the at least one AP hasthe hardware and/or software for synchronizing with the signal from thetiming source. In some embodiments, the timing source may be a globalnavigational satellite system (GNSS) satellite and the signal may be asatellite signal from the GNSS satellite. In these embodiments, thefirst information may further include information indicating whethereach of the at least one AP has a lock on the satellite signal.

At step 5020, a CMF may obtain a network connectivity information of theplurality of APs. In some embodiments, the network connectivityinformation may include a network map. At step 5030, a TMF may designatea first AP of the plurality of APs as a master node based on the firstinformation and the network connectivity information. At step 5040, theTMF may assign a second AP of the plurality of APs as a slave node tothe master node based on the first information and the networkconnectivity information.

While illustrative embodiments have been described herein, the scope ofany and all embodiments having equivalent elements, modifications,omissions, combinations (e.g., of aspects across various embodiments),adaptations and/or alterations as would be appreciated by those skilledin the art based on the present disclosure. The limitations in theclaims are to be interpreted broadly based on the language employed inthe claims and not limited to examples described in the presentspecification or during the prosecution of the application. The examplesare to be construed as non-exclusive. Furthermore, the steps of thedisclosed routines may be modified in any manner, including byreordering steps and/or inserting or deleting steps. It is intended,therefore, that the specification and examples be considered asillustrative only, with a true scope and spirit being indicated by thefollowing claims and their fill scope of equivalents.

What is claimed is:
 1. A method of clock synchronization in a networkcomprising a plurality of access points (APs), the method comprising:receiving first information from at least one AP in the network, thefirst information indicating whether each of the at least one AP is ableto synchronize with a reference signal from a timing source; obtainingnetwork connectivity information of the plurality of APs; anddesignating a first AP of the plurality of APs as a master node based onthe first information and the network connectivity information;assigning a second AP of the plurality of APs as a slave node to themaster node based on the first information and the network connectivityinformation, the slave node to synchronize its clock to timinginformation provided by the master node.
 2. The method of claim 1,wherein a timing management function (TMF) designates the first AP asthe master node and the second AP as the slave node.
 3. The method ofclaim 2, wherein a location management function (LMF) receives the firstinformation from the at least one AP in the network.
 4. The method ofclaim 3, wherein the LMF and TMF are separate services executing on atleast one cloud platform.
 5. The method of claim 3, wherein aconnectivity management function (CMF) obtains the network connectivityinformation.
 6. The method of claim 5, wherein the CMF and TMF areseparate services executing on at least one cloud platform.
 7. Themethod of claim 4, wherein the LMF comprises a distributed portion and acloud portion, and the LMF receives the first information through thedistributed portion executing on the at least one AP.
 8. The method ofclaim 1, wherein the first information comprises information indicatingwhether each of the at least one AP has at least one of hardware andsoftware for synchronizing with the reference signal from the timingsource.
 9. The method of claim 1, wherein the timing source is a globalnavigational satellite system (GNSS) satellite and the reference signalis a satellite signal from the GNSS satellite.
 10. The method of claim9, wherein the first information comprises information indicatingwhether each of the at least one AP has a lock on the satellite signal.11. The method of claim 1, wherein the network connectivity informationincludes a network map.
 12. The method of claim 1, wherein the firstinformation comprises (i) information indicating whether the at leastone AP is configured to receive the reference signal from the timingsource, and (ii) information indicating whether the at least one AP isconfigured to synchronize to the reference signal.
 13. A system forsynchronizing clocks of a plurality of access points (APs) in a network,the system comprising: a location management function (LMF) configuredto receive first information from at least one AP of the plurality ofAPs, the first information indicating whether each of the at least oneAP is able to synchronize with a reference signal from a timing source;a connectivity management function (CMF) configured to obtain networkconnectivity information of the plurality of APs; and a timingmanagement function (TMF) configured to: designate a first AP of theplurality of APs as a master node based on the first information and thenetwork connectivity information, and assign a second AP of theplurality of APs as a slave node to the master node based on the firstinformation and the network connectivity information, the slave node tosynchronize its clock to timing information provided by the master node.14. The system of claim 13, wherein the LMF, CMF, and TMF are servicesexecuting on at least one cloud platform.
 15. The system of claim 13,wherein the LMF is configured to receive the first information through adistributed portion of the LMF executing on the at least one AP.
 16. Thesystem of claim 13, wherein the first information comprises informationindicating whether each of the at least one AP has at least one ofhardware and software for synchronizing with the reference signal fromthe timing source.
 17. The system of claim 13, wherein the timing sourceis a global navigational satellite system (GNSS) satellite and thereference signal is a satellite signal from the GNSS satellite.
 18. Thesystem of claim 17, wherein the first information comprises informationindicating whether each of the at least one AP has a lock on thesatellite signal.
 19. The system of claim 13, wherein the networkconnectivity information includes a network map.
 20. The system of claim13, wherein the first information comprises (i) information indicatingwhether the at least one AP is configured to receive the referencesignal from the timing source, and (ii) information indicating whetherthe at least one AP is configured to synchronize to the referencesignal.
 21. A system for clock synchronizing in a network comprising aplurality of access points (APs), the system comprising: means forreceiving first information from at least one AP of the plurality ofAPs, the first information indicating whether each of the at least oneAP is able to synchronize with a reference signal from a timing source;means for obtaining network connectivity information of the plurality ofAPs; and means for designating a first AP of the plurality of APs as amaster node based on the first information and the network connectivityinformation and assigning a second AP of the plurality of APs as a slavenode to the master node based on the first information and the networkconnectivity information, the slave node to synchronize its clock totiming information provided by the master node.
 22. The system of claim21, wherein the timing source is a global navigational satellite system(GNSS) satellite and the reference signal is a satellite signal from theGNSS satellite.
 23. The system of claim 22, wherein the firstinformation comprises information indicating whether each of the atleast one AP has a lock on the satellite signal.